home *** CD-ROM | disk | FTP | other *** search
/ ETO Development Tools 1 / ETO Development Tools 1.iso / Essentials / MacApp Documentation / MacApp AppleLink Messages / MacApp.Tech$ 4⁄13⁄90 / 1082-Re MacApp and code r-Apr90 < prev    next >
Encoding:
Text File  |  1990-04-16  |  5.2 KB  |  111 lines  |  [TEXT/GEOL]
  1. Item forwarded  by  A33          to A34
  2.  
  3. Item    3568245                         12-April-90        12:55PDT
  4.  
  5. From:   POWERUP.ENG                     Power Up Software,PRT
  6.  
  7. To:     MACAPP.TECH$                    MacApp Technical
  8.         ROSENSTEIN1                     Rosenstein, Larry
  9.  
  10. Sub:    Re-MacApp and code resour
  11.  
  12. Attn:   MacApp.Tech$
  13. Attn: Larry Rosenstein
  14. SentBy: James Plamondon
  15. Date   4/13/90
  16. Subject    Re-MacApp and code resourc
  17. From   James Plamondon
  18. To EHN & DIJ Oakley,IDV, Larry Rosenstein
  19. CC   MacApp.Tech$
  20.  
  21. Subject:   Re-MacApp and code resourc
  22. Dear Larry, Howard, et al.,
  23.  
  24. Thanks for your responses to my link regarding the use of external code
  25. resources in MacApp.
  26.  
  27. To sum up your responses:  one cannot write an external code resource (such as
  28. an XCMD, an MDEF, etc.) in Object Pascal, but one can access such an external
  29. code resource from Object Pascal and (thus) from a MacApp program just as one
  30. would from any other kind of program.
  31.  
  32. Assuming that this summation is correct, let me take this discussion a step
  33. further — to wrapping up the external code resources in a class, as Larry
  34. mentioned one could do.
  35.  
  36. One can imagine a class, TCust, which encapsulates a custom code resource such
  37. as that described in Tech Note #135 (Getting Through CUSToms), and another
  38. class, TCustManager, which deals with groups of TCust objects.
  39.  
  40. The TCustManager class could search in the appropriate places (folders and/or
  41. files) for resources of type 'CUST' (exactly how this is done is not
  42. relevant).  For each 'CUST' resource found, it would create a new object of
  43. class TCust, and keep track of it somehow (in a list or some such — again, the
  44. details don't matter).  Each TCust object would contain a reference to the
  45. ‘CUST’ resource it encapsulated (of course).  The TCust class would contain
  46. wrappers for whatever messages the 'CUST' resource recognized.  For example,
  47. ICust() would send the 'CUST' resource an initialization message, TCust.Free()
  48. could send it a cleanup message, and various other methods would send other,
  49. appropriate messages.
  50.  
  51. Of course, sending a message to a code resource is not implemented in the same
  52. way as sending a message to an object.  Just as in a WDEF, CDEF, MDEF, or any
  53. other code resource, the code resource's main routine is called with a integer
  54. message selector.
  55.  
  56. In the 'CUST' Tech Note (#135), Rick Blair, the author, recommends passing in
  57. the address of some of the application's globals as a parameter to the 'CUST'
  58. resource's main routine.  I think that this is generally frowned on now, and
  59. that instead, a reference to a parameter block is passed in instead, along
  60. with the message selector.
  61.  
  62. So, the MacApp application can communicate just fine with the 'CUST'
  63. resources, because they are neatly encapsulated in TCust objects.  But, can
  64. the 'CUST' resources communicate back to the MacApp application?  They
  65. certainly can't make method calls, even if they are given references to MacApp
  66. objects, because these methods weren't linked into the 'CUST' resources.
  67.  
  68. What the 'CUST' resources CAN do is call a single global routine — let's call
  69. it RequestService() — in the MacApp application.  Each 'CUST' resource is
  70. passed a reference to this global routine (which must reside in a locked
  71. segment) during its initialization, along with a reference to the TCust object
  72. that encapsulates it.  The 'CUST' resource calls RequestService(), passing in
  73. a message selector, the reference to its TCust wrapper, and a parameter block.
  74.  RequestService() then calls the given TCust object's TCust.RequestService()
  75. method with the given info.  TCust.RequestService() contains a big, ugly CASE
  76. statement on the message selector.  Each of the various case clauses can do
  77. whatever it needs to do, including calling MacApp methods.  Thus, the ‘CUST’
  78. resource can communicate with MacApp.
  79.  
  80. In summary, it appears to me that it is not only possible, but downright easy
  81. to use custom resources such as XCMDs to extend programs written in MacApp.
  82. While it’s true that such external resources cannot themselves be written in
  83. MacApp, or even in Object Pascal, this is no great hardship; the mechanism of
  84. having the code resource call an application  global routine with a
  85. message-selector-and-parameter-block to request services of the application
  86. has to be done in non-MacApp programs too, and in them, it is usually less
  87. well encapsulated than it would be in a MacApp program.
  88.  
  89. Why am I so interested in this?  Because, first of all, I’m planning to use
  90. external code resources in my MacApp program, and I want to make sure there
  91. are no wholes in my proposed mechanism before I spend a lot of time
  92. implementing it.
  93.  
  94. Also, I’m interested because my ex-associate was actually WRITING HIS OWN
  95. OBJECT SYSTEM FROM SCRATCH because somebody told him that he couldn’t use
  96. external code resources in MacApp.  Think of the incredible amount of time
  97. he’s going to waste!  I’d love to be able to set him straight, and save him
  98. about ten man-years of development time — but only if my scheme will work (of
  99. course).
  100.  
  101. So — can anybody find any big theoretical or practical problems with the
  102. scheme I’ve outlined above?  I deeply appreciate your assistance in this
  103. matter.
  104.  
  105. Looking forward to your responses, I remain
  106.  
  107. Yours,
  108.  
  109. James Plamondon
  110.  
  111.